Introduction

LINUX is probably the Unix-like operating system that supports the widest variety of hardware devices. The reasons for this are presumably

The vast choice and openness has lead not only to a wide support of hardware devices, but also to a certain divergence in behavior. Especially for CDROM devices, the way a particular drive reacts to a `standard' ioctl () call varies a lot from one brand to another; however, the LINUX CDROM driver writers kept away from wilderness by the practice of evolving a new driver by copying, understanding and changing an existing one.

Since the beginning of the CDROM, many different interfaces developed. Some of them had their own proprietary design (Sony, Mitsumi, Panasonic, Philips), other manufacturers adopted an existing electrical interface and changed the functionality (CreativeLabs/SoundBlaster, Teac, Funai) or simply adapted their drives to one or more of the already existing electrical interfaces (Aztech, Sanyo, Funai, Vertos, Longshine, Optics Storage and most of the `NoName' manufacturers). In cases where a new drive really brought his own interface or used his own command set and flow control scheme, either a separate driver had to be written, or an existing driver had to get enhanced.

Nowadays, almost all new CDROM types are either ATAPI/IDE or SCSI; it is very unlikely that any manufacturer still will create a new interface, and new drives for the existing proprietary interfaces are getting rare. But history has delivered us CDROM support for many different interfaces.

When (in the 1.3.70's) I looked at the existing interface which is expressed through cdrom.h it appeared to be a rather wild set of commands and data formats.1 It seemed that many features of the interface have been added to include certain specific capabilities of certain drives, in an ad hoc manner. More importantly, it appeared that actual execution of the commands is different for most of the different drivers: e.g., some drivers close the tray if an open() call occurs while the tray is unloaded, while others do not. Some drivers lock the door upon opening the device, to prevent an incoherent file system, but others don't, to allow software ejection. Undoubtedly, the capabilities of the different drives vary, but even when two drives have the same capability the driver behavior may be different.

I decided to start a discussion on how to improve uniformity, addressing all CDROM-driver developers found in the various driver files. The reactions encouraged me to write a uniform (compatible) software level cdrom.c to which this document is the documentation. In the mean time, the data structure definitions in cdrom.h had been cleaned up a lot—which was very helpful for the new code.

[Apparently, not all CDROM developers support this initiative. They—mainly those who used the already existing drivers not only as a coding example, but also as a `user interface' reference during their own development—have taken care that cdrom.h reflects a software interface to `user programs' which is unique between all drivers as much as possible; these driver writers will continue to refine the existing cdrom.h where it seems necessary, and they tend to look if any newly requested functionality isn't already there before they are ready to define new structures. The sbpcd driver gives an example that it is possible to let a robot arm play juke box—either with audio or with data CDs—and that it is possible to let the juke box work on even if a disk has fallen upon the floor and the drive door has closed without having a disk inside; without any new software layer or any structures which are not already present in cdrom.h. This `other' group of LINUX CDROM driver writers explicitly does not support the idea to define an additional software layer between driver and user program.]=0pt

The effort (cdrom.c) of which this is the documentation is not meant to drive a wedge between two groups of driver developers, but rather to enable sharing of `strategic code' among drivers. The code should not be viewed as a new interface to user-level programs, but rather as a new interface between driver code and kernel.

Care is taken that 100 % compatibility exists with the data structures and programmer's interface defined in cdrom.h, and in order not to interfere with ongoing development in cdrom.h, any `new' data structures have been put in a separate header file called ucdrom.h. Because the data structures of cdrom.h are fully supported, this documentation may also be of help to the programmers using the interface defined in cdrom.h, but this guide is primarily written to help CDROM driver developers adapt their code to use the `common CDROM' code in cdrom.c.

Personally, I think that the most important hardware interfaces will be the IDE/ATAPI drives and of course the SCSI drives, but as prices of hardware drop continuously, it is not unlikely that people will have more than one CDROM drive, possibly of mixed types. It is important that these drives behave in the same way. (In December 1994, one of the cheapest CDROM drives was a Philips cm206, a double-speed proprietary drive. In the months that I was busy writing a LINUX driver for it, proprietary drives became old-fashioned and IDE/ATAPI drives became standard. At the time of writing (April 1996) the cheapest double speed drive is IDE and at one fifth of the price of its predecessor. Eight speed drives are available now.)

This document defines (in pre-release versions: proposes) the various ioctls, and the way the drivers should implement this.